1. Technical Field
The invention relates generally to computer systems, and more particularly relates to a processor that uses a core clock that is a 1/2X multiple of the system clock.
In an exemplary embodiment, the invention is used in an x86 processor to interface a processor core with a 233 or 300 MHz core clock to a bus controller operating at a 66 MHz system clock frequency.
2. Related Art
Current microprocessor designs typically use a core clock rate that is some multiple of the bus or system clock rate. For example, in a computer system with a 66 MHz system clock, a 4X core clock will enable the microprocessor to run at 266 MHz.
For microprocessors employing clock multiplication, the bus controller (bc) provides an interface between the microprocessor core and the external system. Clock generation circuitry receives the input bus/system clock, and generates both a bc clock at the bus clock frequency, and a multiplied core clock--the bc operates internally with the bc clock, and interfaces to the external bus at the bus clock frequency, and to the core at the core clock frequency.
Without limiting the scope of the invention, this background information is provided in the context of a specific problem to which the invention has application: in a microprocessor, interfacing the bus controller to the execution core when the core is using a core clock that is a 1/2X multiple of the bc clock.
Clock generators able to provide a core clock that is an integer multiple of an input bus/system clock are straightforward in that the rising edge of the bus clock is synchronized with the rising edge of multiplied core clock.
Even in the case of two phase designs, all clock edges are synchronized. Two phase microprocessor designs use separate ph1 and ph2 core clocks that are 180 degrees out of phase--the separate ph1/ph2 clocks are used to clock different sets of ph1 and ph2 latches in the core logic. Some microprocessors use a two phase design for the bus controller also, so that the bc uses bph1 and bph2 clocks at the bus clock frequency (which clock bph1 and bph2 latches in the bc logic).
Incorporating clock generation support for 1/2X clocking is advantageous in providing flexibility to the computer system designer. For example, in the case of a 66 MHz bus/system clock, the computer system designer could offer both a 4X clocked 266 MHz system and/or a 4.5X clocked 300 MHz system.
One-half X clocking is problematic in that not all of the clock edges of the bus and multiplied core clocks are in sync. Thus, in the case of a two phase microprocessor design, for even clock cycles of the bc clocks, the rising edges of the core clocks ph1/ph2 are in phase with the rising edges of the corresponding bc clocks bph1/bph2, but for odd clock cycles of bph, the rising edges of the bc clocks occur on corresponding falling edges of the core clocks (i.e., the core and bus clocks are out of phase by approximately 1/2 of a core clock period).
This lack of synchronization between core and bus clocks is illustrated in FIG. 2 (bph1 and ph1)--it can have a significant impact on interface timing (hand shaking) between the core and bc logic. For example, data accesses by the execution core are typically presented to an L1 (level 1) cache--if the cache accesses misses, the cache controller requests that the bus controller run an external bus cycle to retrieve the data.
In the case of out-of-phase (odd) bc clock cycles, a 1/2 clock difference can have significant ramifications. For example, when the bc receives a bus cycle request from the cache controller, it will typically run the bus cycle in the same clock as the request is received, and at the same time acknowledge to the cache controller that it has received the request and run the bus cycle--the cache controller is then able to issue another bus cycle request to the bc in the next clock without having to re-run (or re-prioritize) an unacknowledged request.
Thus, if the bc delays acknowledging the first request for 1/2 clock, performance will be adversely impacted because the cache controller will have to re-run (possibly with reprioritization) the unacknowledged request (thus introducing additional delays in supplying requested data to the execution core). If the cache controller is allowed to issue a second request without waiting for the first request to be acknowledged, then additional logic would have to be included in the cache controller to determine whether the next acknowledgement is for the first or second bus cycle request.